Many businesses provide access to their products and services through applications that are delivered over computer networks such as the Internet. These applications typically have a multi-tiered architecture. In those cases where the applications are delivered over the Internet they are commonly referred to as Web-based applications. FIG. 1 is a block diagram of a Web-based application 100 having a multi-tiered architecture.
Web-based application 100 includes client layer 110, application layer 120, and database layer 130. Client layer 110 includes user interface 112 that runs on a client computing device such as a desktop computer, laptop computer, personal digital assistant, telephone, and the like. In a Web-based environment, user interface 112 is typically a Web browser. User interface 112 may collect input from a user and provide that input to application layer 120 for processing.
Application layer 120 includes application server 122 to receive and process input from client layer 110. Application server 122 typically includes a number of subcomponents including, for example, connectivity layer 140, presentation logic 142, business logic 144, and database interface 146. Connectivity layer 140 provides connections to client layer 110 using protocols such as the HyperText Transfer Protocol (HTTP), HTTP secured through the Secure Socket Layer, the Simple Object Access Protocol (SOAP), and the like. Presentation logic 142 generates a Graphical User Interface (GUI) using, for example, a markup language such as the Hyper Text Markup Language (HTML). Business logic 144 represents the core of the application, for example, the rules governing the underlying business process (or other functionality) provided by the application. The Java 2 Enterprise Edition Specification v1.3, published on Jul. 27, 2001 (the J2EE Standard) defines an increasingly popular architecture for application layer 120.
Database layer 130 includes data access logic used by business logic 144 to store and retrieve data in database 132. Database 132 provides non-volatile storage (sometimes referred to as a persistent store) for the data accessed and/or processed by application layer 120. Database 132 may be, for example, a relational database or an object-oriented database.
Database interface 146 provides an interface between business logic 144 and database layer 130. Database interface 146, for example, establishes (and terminates) connections between business logic 144 and database layer 130. Business logic 144 accesses database tables (and, in some cases, a data dictionary) via database interface 146. Typically, database interface 146 controls the access of database tables using transactions. The term “transaction” refers to a series of database operations that form a unit with regard to backup and synchronization (e.g., a read transaction or a write transaction).
The operations of one transaction may generate data inconsistencies for the operations of another transaction. The three most common types of data inconsistencies are: dirty reads, non-repeatable reads, and phantom reads. The term “dirty read” refers to reading data before it is committed to a database and that is, subsequent to the read, rolled-back. The term “non-repeatable read” refers to data that is read twice during a transaction and modified subsequent to the first read but before the second read. The term “phantom read” refers to reading a set of database table rows twice during a transaction. If a new row is inserted after the first read and before the second read, then the new row appears to be a “phantom” because it did not exist during the first read.
Transaction isolation levels determine the extent to which the operation of one transaction affects the operation of another transaction. For example, the more isolated one transaction is from another, the more consistent the accessed data may be. Transaction isolation levels are typically implemented by placing locks on the rows in a database table. Placing locks on the rows of a database table, however, may limit the number of concurrent data accesses that are possible. If too many locks are placed on the table, then the performance of the database may be reduced. Alternatively, if too few locks are placed on the database, then the accessed data may be inconsistent.